Schwab - Skill Attribution Fix

Many organizations implement pre-queue decision logic to enhance contact routing efficiency. While effective for operational responsiveness, this approach can introduce challenges in maintaining accurate skill attribution for workforce management forecasting. This document outlines a solution designed to restore primary skill integrity by leveraging custom field data and cloud-native services.

What Happened

Charles Schwab’s overflow skilling logic routes contacts from the original skill to an answering skill (In queue), disrupting accurate skill attribution in IEX WFM. To maintain forecasting integrity, the original skill (pTargetSkill) must be retained and reported, but this was lost when Charles Schwab transitioned to the True to Interval (TTI) paradigm in March 2024.

Solution

To resolve this, a new Stream Consumer was developed to capture and store the pTargetSkill value from custom contact fields. This value is then used to override the SKILL_NO field in contact and agent interval data models, ensuring accurate reporting to IEX WFM.

Key Benefits

  • Restores accurate skill attribution for forecasting.

  • Maintains an audit trail via the ORIGINAL_SKILL_NO field.

  • Supports scalable deployment (initially in the NA1 region).

High-Level Architecture

Key components

  • PTargetSkill: Original Skill Number, before pre-queue decision logic routes to the contact to a new Skill.

  • Kinesis: pTargetSkill will be Published to Kinesis by the VC and Read from Kinesis by Stream Consumer.

  • Stream Consumer: Listens to the <env>-custom-contact-field Kinesis stream and stores pTargetSkill in Redis.

  • State Aggregator: Reads pTargetSkill from Redis and overrides SKILL_NO in DynamoDb models.

  • Interval Aggregator: Uses updated models for accurate queue interval reporting.

  • Snowflake Query: The PTargetSkill values will be stored in snowflake for data recovery upon request.

Data flow diagram

Integration points

Known Limitations

  • This integration is going to capture a pTargetSkill regardless of tenant if on the stream

  • The usage of pTargetSkill can only be confirmed via usage of studio scripts and stream consumer logs and not on the WFM

  • The usage of pTargetSkill changes how Queue Delay Time is calculated. With pTargetSkill enabled, if multiple, consecutive Inqueue events are on the same contact, we will use the time difference between the last Inqueue event and the next non-inqueue event.

    • Queue Delay Time is reported on the Queue Report.

    • More information

FAQs

  • Why was the workaround needed?

    Overflow skilling caused loss of original skill data, negatively impacting IEX forecasting.

  • Is this solution scalable?

    Yes, it’s region-configurable and supports future expansion.

  • What happens if the primary target skill (pTargetSkill) is not captured?

    If the pTargetSkill is not captured, the system will default to reporting the answering skill instead. This is the current behavior.

  • How do we know the data is accurate?

    We’ve added an audit trail using the ORIGINAL_SKILL_NO field, so any overrides are traceable. This ensures transparency and supports troubleshooting if needed.

Document Revision History

Revision

Date

Description
1.1 8/20/25 Added known limitation for Queue Delay Time calculation.
1.0 8/15/2025 Initial version of document.